1. Field of the Invention
The present invention relates to the improvement of a network system using an IPv4/IPv6 translator that performs address translation between an IPv6 terminal that uses IPv6 (Internet Protocol version 6) as the communication protocol thereof and an IPv4 terminal that uses IPv4 (Internet Protocol version 4) also as the communication protocol thereof.
2. Description of the Related Art
Patent document 1 mentioned below discloses the technology intended to make mobile IP communication possible in an environment where IP networks using a plurality of IP protocol versions coexist.
However, patent document 1 is specifically concerned with a mechanism whereby an IPv6 node belonging to an IPv6 network notifies a home agent of the node's current position when the node has moved out to an IPv4 network.
In contrast, the present invention relates to a mechanism designed for the IPv6 node to notify the IPv4/IPv6 translator of the node's care-of address when the IPv6 node moves out of the home link to an external link within the IPv6 network. Thus, the present invention differs from the invention described in patent document 1 in that the IPv6 node does not move out to the IPv4 network.
Patent Document 1:
Japanese laid-open patent application 2002-328869
FIG. 1 is a schematic block diagram illustrating an example of a network system that uses a conventional IPv4/IPv6 translator.
In FIG. 1, IPv4/IPv6 translator 30 bilaterally translates packets between IPv6 and IPv4 protocols in communication between IPv6 node 11 belonging to IPv6 network 10 and IPv4 node 21 belonging to IPv4 network 20, thus making communication possible between nodes with different protocols.
On the other hand, Mobile IPv6 (hereinafter referred to as MIPv6) has been proposed as another IPv6 protocol functionally enhanced for use with mobile nodes. With this MIPv6, it is possible for a mobile node to move between IPv6 networks by using a permanent IP address (home address), while maintaining an ongoing communication link. When communicating with a target correspondent node from an external link using a route optimization function, the mobile node sends an HOTI (Home Test Init: home test initialization) packet and a COTI (Care-of Test Init: care-of test initialization) packet to the correspondent node.
FIG. 2 is a schematic block diagram illustrating system operation when correspondent node 50 has no route optimization function. Correspondent node 50 returns ICMP (Internet Control Management Protocol) error packets (3) and (4) in response to COTI (1) or HOTI (2) packets sent from mobile node 42. Upon receipt of ICMP error packet (3), mobile node 42 immediately stops resending HOTI (2) and COTI (1) packets, and does not conduct any route optimization procedure. At this point, mobile node 42 communicates with correspondent node 50 through home agent 41 by using a bidirectional tunnel, as shown in FIG. 3.
FIG. 4 is a schematic block diagram illustrating system operation when correspondent node 50 has a route optimization function. If correspondent node 50 has a route optimization function, the node returns an HoT (4) packet (Home Test: home test) and a CoT (3) packet (Care-of Test: care-of test) respectively, in response to HoTI (2) and to CoTI (1) packets sent from mobile node 42. Upon receipt of these packets, the mobile node immediately stops resending the HoTI (2) and CoTI (1) packets, and proceeds to a position registration procedure shown in FIG. 5 to conduct the route optimization procedure. The position registration procedure is completed when mobile node 42 sends a binding update (BU) packet to correspondent node 50 and the correspondent node returns a binding acknowledgement (BA) packet as necessary, as shown in FIG. 5. Hereafter, mobile node 42 can communicate directly with correspondent node 50 without routing through home agent 41, as shown in FIG. 6.
When mobile node 42 conducts the route optimization procedure through IPv4/IPv6 translator 30 by means of communication with IPv4 node 21 as shown in FIG. 7, IPv4/IPv6 translator 30 receives an HoTI packet formatted as shown in FIG. 8 and a CoTI packet formatted as shown in FIG. 9, from mobile node 42.
The HoTI packet of FIG. 8 is composed of an IPv6 header and a mobility header. The source address of the IPv6 header denotes a home address and the destination address thereof denotes a virtual IPv6 address corresponding to an IPv4 address. The type of the mobility header is HoTI.
The CoTI packet of FIG. 9 is also composed of an IPv6 header and a mobility header. The source address of the IPv6 header denotes a care-of address generated at a point to which the mobile node has moved and the destination address denotes the virtual IPv6 address corresponding to the IPv4 address. The type of the mobility header is CoTI.
In MIPv6, the mobility header is defined as an IPv6 extension header. In addition, an IPv4/IPv6 translator that utilizes the exiting NAT-PT specification ignores the IPv6 extension header according to the specification. Therefore, it is not possible for the conventional IPv4/IPv6 translator 30 to prevent HoTI and CoTI packets from being re-sent from mobile node 42 (see FIG. 7). Nor is it possible to use an optimized route for communication between mobile node 42 and IPv4/IPv6 translator 30. Accordingly, communication is always carried out by way of home agent 41 using the bidirectional tunnel, as shown in FIG. 10.
In other words, according to the conventional system configuration, although the route optimization procedure is conducted under normal conditions when mobile node 42 carries out communication from an external link, it is not possible to prevent HOTI and CoTI packets from being re-sent from mobile node 42 at that time. This results in the problem that the amount of load on mobile node 42 increases.
In addition, it is not possible for mobile node 42 to use an optimized route leading to IPv4/IPv6 translator 30. This results in another problem that the amount of traffic from mobile node 42 to IPv4/IPv6 translator 30 increases.
Furthermore, mobile node 42 always carries out communication by way of home agent 41, using the bidirectional tunnel. This results in yet another problem that it is not possible for IPv4/IPv6 translator 30 to know which network mobile node 42 is actually moving toward.